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© For each access plan 14, 16 in a database 
system 10. dependencies are determined for each 
database object 20, 22 on which that access plan is 
dependent Each dependency has a type. When a 
relationship changes between database objects, the 
dependency types of each access plan for those 
objects is determined. If an access plan has depen- 
dencies on the affected database objects which fall 
within a preselected subset of dependency types, 
that access plan is invalidated (and subsequently 
recompiled). If the access plan dependencies are not 
within the preselected subset of dependency types, 
the plan remains valid and need not be recompiled. 
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A METHOD FOR INVALIDATING ACCESS PLANS IN A DATABASE SYSTEM 


Field of the Invention 

The present invention relates generally to 
database systems for digital computers, and more 
specifically to a method for invalidating access 
plans therein to ensure referential integrity within 
the database during certain operations. 


Background of the Invention 


In order to increase the speed of database 
access in digital computer systems, source files 
containing database access commands can be 
compiled into access plans. The access plans con- 
tain low level procedural statements to access 
databases efficiently. Instead of interpreting 
database access commands at run time in a 
database manager, the access plans are executed 
to improve system performance. 

Numerous constraints must be satisfied when 
updating a database in order to maintain its re- 
ferential integrity. Referential integrity refers to a 
state of consistency across the database. Proce- 
dural code to enforce these constraints can be 
included in the access plans. Each time the data 
base is updated, procedural code in the access 
plans performing such update is executed to per- 
form all of the necessary consistency checks. 

When a change is made in a relationship be- 
tween two database objects, such as tables, the 
constraints which must be checked to ensure re- 
ferential integrity must also be changed. This 
means that access plans which depend upon the 
changed relationship must be recompiled, also 
known as rebinding. 

When an access plan is created, a table of all 
dependencies of that plan on other database ob- 
jects is created. In current systems, if a changed 
relationship affects any of the database objects on 
which an access plan is dependent, that access 
plan is invalidated. Before an invalidated access 
plan can be executed, it must be recompiled. The 
process of recompilation will take into account the 
changed relationship. A change in a single relation- 
ship can possibly affect a large number of access 
plans, each of which must be recompiled prior to 
being executed in the future. Compilation of com- 
mands into access plans is a time consuming 
process, which is preferably avoided if possible. 

Disclosure of the Invention 


Accordingly, the invention provides a method 


for identifying access plans as invalid in a database 
system, comprising the steps of: 
if a relationship between a dependent and a parent 
object changes by dropping, or adding a foreign 

s key in the dependent object for which the parent 
object has a primary key, determining for each 
access plan whether any procedural code within 
the access plan must be change; and 
identifying as invalid all access plans for which any 

70 such procedural code must be changed. 

Preferably the determining step comprises the 
steps of: 

determining types of access plan dependencies on 
the dependent and parent objects; and 

is selecting access plans having dependencies on the 
parent and dependent objects which are within a 
preselected subset of all possible dependency 
types, wherein the procedural cod© within such 
selected access plans must be changed. 

20 The possible dependency types comprise se- 
lect delete, insert update, cascade, and key de- 
pendencies, and the preselected subset comprises: 
when the foreign key is added, insert and update 
dependencies on the dependent object and delete, 

25 update, and cascade dependencies on the parent 
objects; and 

when the foreign key is dropped, insert depen- 
dency on the dependent table,, delete and cascade 
dependencies on the parent table, combined up- 

30 date dependency on the parent table and key 
dependency on the dependent table, and com- 
bined update dependency on the dependent table 
and key dependency on the parent table. 

The invention maintains the referential integrity 

35 of the database by efficiently determining which 
access plans are invalidated by changed referential 
constraints and which must therefore be modified 
in accordance with the changed referential con- 
straints. Access plans which have been identified 

40 or marked as invalid are recompiled when they are 
next invoked. An advantage of the invention is that 
after a change in the relationship between two 
database objects, access plans are marked as in- 
valid only if the procedural code within access 

46 plans to enforce referential constraints must be 
changed, and so access plans are only recompiled 
when necessary. 

Thus, in accordance with the present invention, 
for each access plan In a database system, depen- 

60 dencies are determined for each database obj ct 
on which that access plan is dependent Each 
dep ndency has a type. When a relationship 
changes between database objects, the dependen- 
cy types of each access plan for those objects is 
determined. If an access plan has dependencies on 
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the affected database objects which fail within a 
pr selected subset of dependency types, that ac- 
cess plan is invalidated, if the access plan depen- 
dencies are not within the preselected subset of 
dependency types, that plan remains valid and 
need not be recompiled. 

In other words, the invention provides a meth- 
od for maintaining referential integrity in a database 
when a relationship between two database objects 
is changed, comprising the steps of: 
determining dependencies of access plans on the 
database objects; 

comparing the determined dependencies to a 
preselected subset of all possible access plan de- 
pendency types, and if the determined dependen- 
cies of an access plan are within the preselected 
subset, marking such access plans as invalid. 

The invention also provides base processing 
system including a relation database, said database 
including means for identifying access plans there- 
in as invalid, said means comprising: 
means for determining for each access plan wheth- 
er any procedural code within the access plan 
must be changed if a relationship between a de- 
pendent object and a parent object changes by 
dropping or adding a foreign key in the dependent 
object for which the parent object has a primary 
key; and 

means for identifying as invalid all access plans for 
which any such procedural code must be changed. 

Brief Description of the Drawings 

Figure 1 is a block diagram illustrating access 
plan dependencies within a database system; 
Figure 2 is a diagram illustrating relationships 
between database objects; 
Figure 3 is a table describing the dependency 
types of selected access plan statements on the 
objects of Figure 2; 

Figure 4 is a flowchart illustrating operation of a 
method for checking access plan dependencies 
when a new foreign key is created; and 
Figure 5 is a flowchart illustrating a method for 
checking access plan dependencies when a for- 
eign key is dropped. 

Detailed Description 

Figure 1 illustrated a portion of a database 
system which runs on a general purpose digital 
c mputer as known in the art The system includes 
a database 10 and a database manager 12. The 
database 10 contains a plurality of various typ s of 
objects including data and other types of objects 
used to access data. The database manager 12 is 
called by application programs (not shown) to per- 


form accesses of the databas 10. All access to 
the database 10 is accomplish d through the 
database manager 12. 

Database 10 includes access plan objects 14, 
6 16, 18 and data table objects 20, 22, 24, 26, 28. 
Additional objects and object types will be found in 
a typical database, but are not included here for 
purposes of clarity. Each of the access plan ob- 
jects 14, 16, 18 corresponds to a single source file 

to of high level database access commands which 
has been compiled into low level procedural state- 
ments. When an application program calls the 
database manager 12 to execute a series of 
database access commands, the database man- 

is ager 12 invokes the appropriate access plan to 
accomplish those database accesses. 

Data table objects 20 through 28 each repre- 
sent a table of data consisting logically of rows and 
columns. Each row is a single entry, and is divided 

20 into fields corresponding to the columns of the 
table. As is known in the art, the data table objects 
20 through 28 appear logically as a two dimen- 
sional array, but are typically implemented using 
various types of data structures such as B-trees. 

25 Each access plan 14, 16, 18 has one or more 

data table objects which are affected by its execu- 
tion. An access plan is said to be dependent on 
such data objects. The types of dependencies 
which may exist are described below in further 

30 detail. In database 10, plan 14 is dependent on 
data objects 20, 22, and 24. Plan 16 is dependent 
on objects 24, 26, and 28. while plan 18 is depen- 
dent on objects 26 and 28. In an actual system, the 
number of database objects on which an access 

35 plan is dependent may be quite large. 

In order to ensure the accuracy and consis- 
tency of data contained in the database 10, the 
data must have a quality referred to as referential 
integrity. When the database is updated, referential 

40 integrity is ensured by enforcing restrictions on 
data changes called referential constraints. Some 
terminology necessary to understand the present 
invention will now be defined. 

A primary key is a set of columns in a table 

45 that must contain unique non-null values. A table 
cannot have more than one primary key. A foreign 
key is a set of columns in a table whose values are 
required to match those of the primary key of a 
table. A referential constraint is a requirement that 

so non-null values of a designated foreing key are 
valid only if they also appear as values of the 
primary key of the designated table. A relationship 
defined by a refer ntial constraint is a set of con- 
nections between the r ws of a single table or 

55 between the rows of two different tab! s deter- 
mined by the values of a primary k y and a foreign 
key. 

A parent table Is the tab! in a r lationship 
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containing th primary key that defines the relation- 
ship. A tabl can be a parent in an arbitrary num- 
ber of relationships. A dependent table is a table in 
a relationship containing the foreign key that de- 
fines the relationship. A table can be a dependent 
in an arbitrary number of relationships. A table can 
be both a parent and a dependent 

A dependent row is a row of a dependent table 
that has a foreign key value which matches a 
primary key value of its parent table. The foreign 
key value thus represents a reference from the 
dependent row to a parent row. A parent row is a 
row of a parent table that has at least one depen- 
dent row. 

A delete rule is associated with each referential 
constraint The delete rule can restrict (prevent) the 
deletion of a parent row, or it may specify the 
effect of a deletion on the dependent rows. The 
effect can either be the deletion of the dependent 
rows {cascading of the delete), or the setting of the 
foreing key in the dependent rows to null. 

An update rule is also associated with each 
referential constraint One approach to handling 
update rules is to restrict the updating of a primary 
key in a parent row. Another approach is to specify 
the effect of an update on the dependent rows, so 
that for example, cascading of updates would be 
possible. 

Figure 2 illustrates some of the concepts just 
described. Five data tables, T1 , T2, 73, T4, and T5 f 
are shown. Each table in Figure 2 contains a row 
which illustrates a portion of the format for each 
row in that table. For example, each row in table T1 
includes a column, or group of columns, which 
forms a key A. Each row of table T4 includes keys 
A, C, and B. 

Tables T1, T2, and T4 contain primary keys. 
Table T1 contains primary key A. T2 contains 
primary key B, and T4 contains primary key C. 
Tables T3 f T4, and T5 contain foreign keys. Both 
T3 and T4 contain key A as a foreign key. T4 also 
Includes key B s a foreign key. Table T5 contains 
key C as a foreign key. 

Relations between the tables are indicated by 
the arrows. Arrow 30 represents the relationship 
between foreign key A of table T3 and primary key 
A of T1 . Arrow 32 represents the relationship be- 
tween foreign key A of table T4 and primary key A 
of table T1. Arrow 34 represents the relationship 
between foreign key B of table T4 and primary key 
B of table T2. and arrow 36 represents the relation- 
ship between foreign key C in table T5 and primary 
key C in T4. 

The referential constraints which define rela- 
tionships 30-36 require consistency between en- 
tries stored in related tables. For example, the C 
key for each row of table T5 must match a C key 
in some row of T4, or else contain the-valu null. In 


a similar manner, each row of T4 must be consis- 
tent with both tables T1 and T2. That is, each row 
in T4 must have an A key which matches an A key 
in T1 f and also a B key which matches a B key in 

5 table T2. If a null value is allowed for some foreign 
key, a value of null for that key satisfies that 
referential constraint 

Each time a change is made to the database, 
all relevant referential constraints must be satisfied. 

io If any are not, the change is not allowed. Enforce- 
ment of the following rules for foreign keys ensures 
referential integrity of the database: 
Insert Rule: When a row is inserted into a depen- 
dent table, each non-null foreign key value in the 

15 inserted row must match some value of the primary 
key of the parent table of the relationship. If any 
referential constraint is violated by an insert opera- . 
tion, an error occurs and no rows are inserted. 
Delete Rules: When a row is deleted from a 

20 parent table, a check is performed to determine 
whether there are any dependent rows in the de- 
pendent table. A dependent row is one which has a 
foreign key value which matches the primary key 
of the row to be deleted. If any dependent rows are 

25 found, the action takes is prescribed by a delete 
rule specified for the foreign key in the dependent 
table. 

Three delete rules can be specified for a for- 
eign key. If the rule is RESTRICT, if any dependent 

so rows are found, an error occurs and no rows are 
deleted, if the delete rule is CASCADE, any depen- 
dent rows in the dependent table are deleted. Any 
other referential constraints on the deleted rows of 
the dependent table must also be satisfied, or an 

35 error occurs and no rows are deleted. For a delete 
rule of SET NULL, if any dependent rows are found 
in the dependent table, all nuliable parts of the 
foreign key are set to null. 
Update Rule: As described above, at least two 

40 alternative update rules exist. One approach is to 
specify the effects of update on the dependent 
rows. Another approach is for the update rule to 
state that when a primary key is updated in a 
parent table, a check is performed to determine 

45 whether there are any dependent rows in the de- 
pendent table. If any dependent rows are found, an 
error occurs and no rows are updated. 
Update foreign key rule: When a foreign key is 
updated in a dependent table, if the foreign key is 

so not null its new value must match some value of 
the primary key of the parent table of the relation- 
ship. If any r f rential constraint is violated by the 
updat operation, an error occurs and no rows are 
updat d. * 

55 It is now possible to describe the access plan 
dependencies referred t in connection with Figure 
1. A table is involved in an access plan operation if 
It or any of its indexes are accessed in that opera- 
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tion. It is not necessary that a table involv d in an 
operation be directly referenced by the database 
access command of the operation. An access plan 
is dependent on all database objects that ar in- 
volved in its operati ns, ven if they are involved 
solely for the enforcement of referential constraints. 
Access plan dependencies are recorded for all 
tables directly referenced in an insert, update, de- 
lete, or select statement and in two special cases. 

For purposes of the preferred embodiment, six 
different types of access plan dependencies may 
exist. Four of these dependency types are applied 
to tables which are directly referenced in database 
access statements which directly affect the table. 
These dependency types are select, insert, update, 
and delete. Two additional types of access plan 
dependencies are also defined. Whenever a table 
is involved because of an update of a primary key 
or a foreign key, a key dependency exists. When- 
ever a table is involved because deletes cascade 
to that table, a cascade dependency exists. 

Figure 3 illustrates a number of access plan 
dependencies which can occur with the data tables 
and constraints defined in Figure 2. Figure 3 is a 
table containing a number of different high level 
database access commands, and indicates the 
types of access plan dependencies caused by 
each command and the tables on which the depen- 
dencies occur. 

Command 40 is a high level command to insert 
a row into table T4. This command, contained 
within an access plan, generates an insert depen- 
dency on table T4. When a new row is inserted 
into table T4, the A and B keys must be checked 
against the entries of tables T1 and T2, respec- 
tively, to ensure that matching entries are found 
therein. 

Command 42 indicates that an entry is to be 
deleted from Table T1 . This command generates a 
delete dependency on Tt. This dependency as- 
sumes that the delete rules for foreign key A in 
tables T3 and T4 are either RESTRICT or SET 
NULL. An example illustrating the appropriate de- 
pendencies when the delete rule is CASCADE is 
described below. 

Command 44 inserts a new row into table T2. 
This generates an insert dependency on table 72. 

Command 46 updates a row in table T2. Com- 
mand 46 changes the value of the B key in the row 
to a new value. This generates an update depen- 
dency on table T2. Since key B is a primary key, a 
key dependency is generated for any tables which 
have a foreign key B. In this case, table T4 is the 
only such table. 

Command 48 updates ajdifferent field of tabl 
T2 to a new value. This g nerates an update de- 
pendency on table T2. Since this other field is 
neither a primary key nor a foreign key, no key 


dependencies are generated. 

Command 50 is used to select one or more 
rows from table T4. This generates a select depen- 
dency on T4. 

5 Command 52 is used to update a row of table 

T4, setting the field of the A key to a new value. 
This generates an update dependency on table T4. 
Since key A is a foreign key, a key dependency is 
generated for the parent table of the A relationship. 

w table T1 in this case. 

Command 54 illustrates the dependencies 
which occur when a CASCADE delete rule is used. 
Assume the delete rule for foreign key B in table 
T4 is CASCADE, and the delete rule for foreign key 

is C in table T5 is also CASCADE. In this instance, 
command 54 generates a delete dependency on 
table T2, and cascade dependencies on tables T4 
and T5. 

Relations between tables change whenever a 

20 new foreign key is created in a table, or whenever 
an existing foreign key is dropped from a table. 
The table in which the new foreign key is created 
or from which it is dropped, can be referred to as 
the "object" table. In previous systems, whenever 

25 a new foreign key is added or an existing foreign 
key dropped, al! access plans having a depen- 
dency on the object table are Invalidated and must 
be recompiled before they can be executed. With 
the designation of different dependency types as 

30 described above, it is possible to determine which 
access plans having a dependency on the object 
table are actually affected by the newly created or 
dropped foreign key. Access plans which are not 
actually affected by such foreign key do not need 

35 to be recompiled, and are therefore not invalidated. 

Figure 4 is a flowchart illustrating a sequence 
of steps which can be use to determine which 
access plans must be invalidated when a new 
foreign key is created. In step 60, a new foreign 

40 key is created in the object table. The remaining 
steps of Figure 4 are performed for each access 
plan which has a dependency on the object table, 
or the parent table in the new referential constraint. 
The dependency of an access plan on the 

45 object table is determined in step 62. If that depen- 
dency is an insert or an update dependency 64, 
the access plan is marked as invalid 66 and must 
be recompiled before execution. If the dependency 
on the object table is not an insert or update 

so dependency 64, the dependency of the access 
plan on the parent table for the newly created key 
is determined 68. If the dependency of the access 
plan on the parent table is a delete, cascade, or 
update dependency 70, the access plan is invalid 

55 72. If th d p ndency on the parent table is not a 
del t . cascad . or update dep ndency 70, the 
access plan remains valid 74 and ne d not be 
recompiled. 
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It is not required that the depend ncy ch cks 
made when a new foreign key is created be per- 
formed in exactly the order set forth in Figure 4. It 
is oniy necessary that the same sets of depen- 
dencies cause invalidation of the access plan. 5 
Thus, whenever a new foreign key is created, an 
access plan must be invalidated if it has either 1) 
an insert or update dependency on the object 
table, or 2) a delete, update, or cascade depen- 
dency on the parent table of the newly created 70 
foreign key. 

Application of the access plan dependency 
rules set forth in Figure 4 will now be described in 
connection with examples of Figure 3. For pur- 
poses of these examples, it wii! be assumed that is 
table T4 is the object table, and foreign key B2 is 
the key which has been newly created in table T4, 
referring B in T2. 

For command 40, an access plan has an insert 
dependency on table T4. This requires that the 20 
access plan be invalidated. When the access plan 
is recompiled, it will be necessary for the compiler 
to insert additional code into the access plan for 
checking the referential constraint between table 
T4 and table T2. This code did not exist previously, 25 
since there was previously no relationship between 
these two tables. 

Command 42 generates no dependency on 
table T2 or T4. Therefore, command 42 does not 
cause invalidation of the access plan. 30 

Command 44 generates an insert dependency 
on table T2, and no dependency on table T4. Since 
an insert dependency on the parent table is not 
one of the dependency types which invalidates a - 
plan, command 44 does not require invalidation of 35 
the access plan. Both commands 46 and 48 gen- 
erate update dependencies on parent table T2. 
which require invalidation of the access plan. 

Command 50 generates a select dependency 
on type T4, which does not invalidate the access 40 
plan. Command 52 generates an update on table 
T4, which does not invalidate the access plan. 
Command 54 generates a delete dependency on 
table T2 and a cascade dependency on table T4. 
The delete dependency on parent table T2 requires 45 
invalidation of the plan. 

The flowchart of Figure 5 indicates the depen- 
dencies which must be checked to determine 
whether an access plan should be invalidated after 
a foreign key has been dropped from the object 50 
table. As was the case with Figure 4, it is not 
important in which order th various dependency 
checks are made. It is, however, Important that th 
correct subset of all possible dependency relation- 
ships be used to invalidate aa access plan. 55 

Step 80 indicates that an existing foreign key is 
dropped from the object table. For each dependent 
access plan, the acc ss plan dependency on the 


parent tabl for the just del ted foreign key is 
determined 82. If the plan has an update depen- 
dency on the parent table 84, the plan dependency 
on the obj ct table is then determined 86. If the 
object table dependency is a key dependency 88, 
the plan is marked as invalid 90. If not. additional 
checks are made. 

If the dependency on the parent table was not 
an update dependency 84, or if it was and the 
dependency on the object table is not a key de- 
pendency 88, a check is made to see if the access 
plan has a delete or cascade dependency on the 
parent table 92. If so, the plan is invalid 94. If not, a 
check is made to see if the plan has a key depen- 
dency on the parent table 96. If so, the depen- 
dency of the access plan on the object table is 
determined 98. If the plan has an update depen- 
dency on the object table 100, it is marked as 
invalid 102. 

If the NO branch was taken from step 96, the 
dependency of the access plan on the object table 
is determined 104. The test of step 106 is per- 
formed either after step 104 or 100 as the case 
may be. In step 106 a check Is made to determine 
whether the access plan has an insert dependency 
on the object table. If so, the plan is marked as 
invalid 108. If non of the dependency combinations 
already checked for are true, the plan remains valid 
110. 

In summary, whenever an existing foreign key 
is dropped, an access plan must be invalided if it 
has any of: 1) an update dependency on the parent 
table for the just dropped foreign key and a key 
dependency on the object table; 2) an insert de- 
pendency on the object table; 3) an update depen- 
dency on the object table and a key dependency 
on the parent table for the just dropped foreign 
key; or 4) a delete or a cascade dependency on 
the parent table for the just dropped foreign key. If 
an access plan has none of the dependencies just 
described, it need not be invalidated when the 
foreign key is dropped. 

Application of the access plan dependency rule 
set forth in Figure 5 will now be described in 
connection with the examples of Figure 3. For 
these examples, it will be assumed that table T4 is 
the object table, and that foreign key B is being 
dropped from table T4. 

For command 40, an access plan has an insert 
dependency on table T4. This requires that the 
access plan be invalidated. The code included in 
the access plan which performed constraint check- 
ing on the B key relationship is no longer valid or 
necessary, and will be omitted upon recompilation. 

Command 42 g nerates no depend ncy on 
table T2 or T4. Therefore, command 42 does not 
caus invalidation of th access plan. 

Command 44 generates an insert dependency 
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on table T2, and no dependency on table T4. This 
does not require invalidation of the access plan. 

Command 46 generates an updat dependen- 
cy on table T2 and a key dependency on tabl T4. 
This causes the access plan to be invalidated. 
Command 48, which generates only an update 
dependency on table T2, does not invalidate the 
plan since there is no key dependency on table T4. 

Command 60 generates a select dependency 
on table T4, which does not invalidate the access 
plan. Command 62 generates an update depen- 
dency on table T4, but no dependency on table T2. 
This does not invalidate the plan. Command 54 
generates a delete dependency on table T2, and a 
cascade dependency on table T4. This requires 
invalidation of the access plan. 

As described above, adding or dropping a for- 
eign key requires invalidating an access plan when 
the access plan has certain types of dependencies 
on the object table and the parent table for that 
foreign key. The dependencies which cause invali- 
dation of an access plan are a subset of all of the 
possible types of dependencies which the access 
plan can have on the object table and the parent 
table. Dependency types which are not included in 
this subset do not required invalidation of the ac- 
cess plan. Thus, in many cases, adding or drop- 
ping a foreign key will not require invalidation of ail 
of the access plans which depend on the table 
containing such key. 

The process for checking types of dependen- 
cies when a foreign key is dropped or created can 
be made very efficient. The access plan depen- 
dencies on objects in the database can be stored 
as bit maps. A straightforward check of the bit map 
for each access plan will indicate whether that 
access plan needs to be invalidated. Since depen- 
dency checks can be made efficiently, the small 
amount of extra time involved in making these 
checks is outweighed by the time saved by not 
recompiling access plans when such recompilation 
is unnecessary. 


ing step comprises the steps of: 
det rmining types of access plan dependencies 
(62, 68) on the dependent and parent objects; and 
selecting access plans having dependenci s on the 
5 parent and dep ndent objects which are within a 
preselected subset of all possible dependency 
types, wherein the procedural code within such 
selected access plans must be changed. 

3. The method of Claim 2. wherein the possible 
io dependency types comprises select, delete, insert, 

update, cascade, and key dependencies. 

4. The method of Claim 3, wherein the preselected 
subset comprises: 

when the foreign key is added (60), insert and 
is update dependencies on the dependent object, and 
delete, update, and cascade dependencies on the 
parent objects; and 

when the foreign key is dropped (80). insert depen- 
dency on the dependent table, delete and cascade 

20 dependencies on the parent table, combined up- 
date dependency on the parent table and key 
dependency on the dependent table, and com- 
bined update dependency on the dependent table 
and key dependency on the parent table. 

25 5. A method for maintaining referential integrity in a 
database comprising the steps of: 
identifying the access plan as invalid, according to 
the method of any preceding claim; 
and further comprising the step of: 

30 recompiling an access plan when it Is next acces- 
sed if such a plan has been identified as invalid. 
6. A data processing system including a relational 
database, said database including means for iden- 
tifying access plans therein as invalid, said means 

35 comprising: 

means for determining for each access plan wheth- 
er any procedural code within the access plan 
must be changed if a relationship between a de- 
pendent and a parent object changes by dropping 

40 or adding a foreign key in the dependent object for 
which the parent object has a primary key; and 
means for identifying as invalid all access plans for 
which any such procedural code must be changed. 


Claims 45 

1. A method for Identifying access plans (14) as 
invalid In a database system (10), characterised by 
comprising the steps of: 

if a relationship between a dependent and parent so 
object changes by dropping (80) or adding (60) a 
foreign key in the dependent object for which the 
par nt object has a primary key, det rmining for 
ach access plan whether any procedural cod 
within th access plan must be changed; and 55 
identifying as invalid all access plans for which any 
such procedural code must be changed. 

2. The method of Claim 1, wherein said determin- 
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